Among developers of workstation software, object-oriented programming (or OOP) is increasingly recognized as an important new programming technology. It offers expanded opportunities for software reuse and extensibility, with improved programmer productivity when compared to conventional software development paradigms. Even so, object-oriented technology has not effectively penetrated major commercial software products to date. In particular, operating-systems have hesitated to embrace the new technology.
As with many new programming technologies, the early expressions of OOP concepts focused on the creation of new languages and toolkits, each designed to exploit some particular aspect. So-called pure object-oriented languages, such as Smalltalk, presume a complete run-time environment (sometimes known as a virtual machine) because their semantics represent a major departure from traditional procedurally oriented system architectures. Hybrid languages such as C++, on the other hand, require less run-time support but sometimes result in tight bindings between programs that provide objects and the client programs that use them. Tight binding between object-providing programs and their clients often require client programs to be recompiled whenever simple changes are made in the providing programs. Examples of such systems are found in U.S. Pat. Nos. 4,885,717; 4,953,080 and 4,989,132.
Because different languages and object-oriented toolkits emphasize different aspects of OOP, the utility of the resulting software is frequently limited in scope. A C++ programmer, for example, cannot easily use objects developed in Smalltalk, nor can a Smalltalk programmer make effective use of C++ objects. Objects and classes implemented in one language simply cannot be readily used from another. Unfortunately when this occurs one of the major benefits of OOP, the increased reuse of code, is severely curtailed. Object-oriented language and toolkit boundaries become, in effect, barriers to interoperability.
In object oriented programming programs are organized into object definitions called classes. Most of these classes are derived classes meaning that they get part of their specification and implementation from another class called their parent class. In order to derive specification and implementation from a parent class the derived class must reference the parent class in its implementation. In addition, the supporting class data structures such as method tables must be built from the implementations of both the derived and the parent class. In the prior art this has resulting in static references between the derived class binary image and the parent class binary image. These static references meant that an application using the derived class could not substitute an alternate parent class for the one referenced by the derived class during the application's execution. This has resulted in a lack of flexibility and has limited the reusability of the derived class.